FWIW, @jeffhandley, I'd prefer a bigger hammer than the piecemeal way we've been approaching this so far. When we run TM exercises (including the ones you've participated in!), recall that we typically prefer listing affirmative expectations and assumptions. We can't possibly guess at all the ways somebody will misuse our stuff, after all. :)

If you look at https://learn.microsoft.com/en-us/dotnet/core/extensions/resources, it explicitly states:

A resource is any non-executable data that is logically deployed with an app.

This is a pretty clear indication that .NET expects resources to be part of the app deployment, which implies that they're on the same side of the trust boundary as the app code itself. The logical conclusion from this is that the .resx / .resources capabilities within .NET carry an implicit assumption that the payloads they're operating over will always be considered trustworthy.

While it's straightforward enough to connect the dots and draw this conclusion oneself, IMO it would be helpful it if were explicitly stated somewhere centrally, perhaps at the https://learn.microsoft.com/en-us/dotnet/core/extensions/resources doc itself. We could consider a blurb along the lines of:

In general, resource files (.resx and .resources) within .NET are considered part of the application deployment and are assumed to be trustworthy, much like configuration. Components which operate over such files are free to rely on this assumption. Developers therefore should not process untrustworthy resource files unless they're using an API explicitly documented as being safe in the face of untrusted data.

Thanks for that suggestion, @GrabYourPitchforks. I'll merge this PR and also follow up with one to github.com/dotnet/docs/blob/main/docs/core/extensions/resources.md to add that blurb.